opentelemetry: Implement batch operation for splitting encoded payloads - #299

Summary

• add reusable CMetrics APIs for splitting encoded OTLP metric requests
• cap each generated request by its total OTLP datapoint count
• preserve resource, scope, metric, and datapoint metadata across batches
• support gauge, sum, histogram, exponential histogram, and summary metrics
• cover exact limits, unlimited mode, invalid input, empty contexts, and all metric types

Why

Some OpenTelemetry endpoints, including AWS CloudWatch, reject requests containing
more than 1,000 metric datapoints. CMetrics previously encoded an entire metrics
context into one OTLP request, leaving downstream consumers such as Fluent Bit
to implement their own protobuf splitting logic.

Moving this functionality into CMetrics provides a reusable ownership-safe API
and keeps downstream OpenTelemetry outputs focused on transport and retry
handling.

Validation

ctest --test-dir build -C Debug -R '^cmt-test-opentelemetry$' --output-on-failure
ctest --test-dir build -C Release -R '^cmt-test-opentelemetry$' --output-on-failure
ctest --test-dir build -C Release --output-on-failure (21/21 tests passed)
MSVC AddressSanitizer focused OpenTelemetry test (1/1 test passed)
git diff HEAD^ HEAD --check

The change is additive and does not alter existing encoder entry points or the
OTLP serialized format. A zero datapoint limit preserves the original payload
exactly, while enabled limits produce independently owned requests containing
no more than the configured number of datapoints.